The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems brought forward in this section.
A System-on-Chip (SoC) platform typically comprises at least one embedded Central Processing Unit (CPU), at least one embedded functional unit (also called an IP in the jargon of the one with ordinary skills in the art) which may be a memory (for instance of the eSRAM type), a Memory Management Unit (MMU), and/or at least one register. The components of the SoC are typically interconnected through an internal bus matrix.
In operation, the SoC platform may be led to manipulate sensitive data, for instance, cryptographic secret keys or unencoded secret data like passwords. To prevent unauthorized access to and/or corruption of these sensitive data, the architecture of the SoC platform may be split into two physically and functionally separated environments: a secure environment for manipulating sensitive data and a public environment for processing non-sensitive data. The secure environment comprises notably one or more dedicated secure memories and/or one or more secure hardware registers to store sensitive data, whereas the public environment may include its own dedicated memories and/or hardware registers to store public data.
This separation is for example implemented by Advanced RISC Machine (ARM) SoC platforms with security extensions, for example the TrustZone technology. A clear frontier between these two environments may be implemented with hardware (HW) and/or software (SW) mechanisms embedded in the processor, in the bus matrix, and in the IPs themselves. This frontier ensures that secure data within the secure environment cannot be accessed by any public component belonging to the public environment. This may typically be the case for normal modes of operation of the platform, wherein memories, IPs and processors are kept powered-on or in retention. However, some power modes are available wherein one or more of the secure components can be powered off, meaning that at least some of their contents have to be saved during the particular mode and be restored thereafter. Such modes may be available for the purpose of optimizing the power strategy of the chip and decrease energy leakages.
A dedicated persistent secure memory, included in the secure environment, may be used to store securely sensitive data present in the secure environment before switching from a power-on mode to an energy saving mode. However, there might be cases where not enough secure memory space is available to save all secure contents. Consequently, in such cases, it may be necessary to store sensitive data outside the secure environment, in a non secure storage for example. It may be desirable that such storage can be made efficiently and securely.
This task is rendered particularly difficult when the SoC platform comprises a CPU having a plurality of cores embedding security extensions, since the sensitive data may be spread between several cores.
Another important issue may be to be able to guarantee data confidentiality and integrity to avoid leakage of secure information in the public environment during periods where secure data are stored in unsecure storage, and to avoid secure data corruption.
Another aspect that may be considered concerns performances since one or several constraints may be inherent for low-power modes. The impact of the constraints on performances may preferably be as low as possible, so that the global platform strategy is not jeopardized.
Thus, embodiments of the present invention aim at solving at least some of the following problems:                How to store sensitive data handled by a multicore system in a first mode of operation, following a request to switch to a second mode of operation.        Ensuring confidentiality and/or integrity for said stored sensitive data.        Limiting impact on system performances.        